ANALYSIS: Network Flow Inventory
Kibana Dashboard: [INVENTORY] Flows

What is this baseline?β
The associated Kibana dashboard represents the deduplicated set of network flow tuples observed within the DAL.
- A flow is defined as:
source.ipdestination.ipdestination.portnetwork.transportnetwork.direction(from the perspective of the DAL)
- Each row answers:
"Has this exact flow ever been observed during the baseline window?"
- This is not NetFlow:
- No session counts
- No byte/packet volumes
- No timing or duration
- Presence-only semantics
- A single observed event is enough to place a flow in the baseline.
- From Zeek logs, only successful connections are counted as a flow.
- Entries are deduplicated by flow tuple
@timestampsignifies when it was last observed- A flow seen once early in the window is equivalent to one seen moments ago
Data Prerequisitesβ
If any of these are missing or incorrect, the baseline is unreliable.
1. DAL / HOME_NET must be correctβ
- Derived from Zeek and/or Suricata
HOME_NET - Used to:
- Filter entries into the inventory
- Infer
network.direction(internal,inbound,outbound,external)
- Incorrect DAL β incorrect directionality β incorrect analysis
2. Required telemetry sources (at least one)β
- Zeek
conn.log(preferred) - Sysmon Event ID
3 - Auditbeat
socket - Endgame network telemetry
NOTE: More sources = more complete baseline. Missing sources = blind spots.
Basic Analysis Workflowβ
1. Baseline sanity checkβ
Before threat analysis, verify the shape of the data:
- Internal β internal flows dominate
- Inbound flows align with known servers
- Outbound flows match expected egress behavior
2. Long-tail analysis (primary value)β
Focus on rare entries
- Sort ascending by flow count in:
source.ipdestination.ipdestination.port
- Prioritize:
- High or unusual ports
- External IPs with single-digit flows
- Inbound flows to non-server hosts
Key questions
- Admin or maintenance activity?
- Scanning?
- One-off tooling?
- Potential beaconing?
Validate findings
- Investigate anomalies and verify conclusions
3. Direction-specific reviewβ
Internal
- Noisy but useful for lateral movement baselines
- Rare internal ports or uncommon host pairings matter
Inbound
- Should be well understood
- Any inbound flow to an unexpected host is suspicious
Outbound
- Highest signal category
- Rare destinations or ports are prime investigation targets
4. Export for reporting and diffingβ
Reporting and documentation requirements are determined by the Mission Element Lead/Crew Lead
Common exports
- Full Inventory table (CSV)
NOTE: These exports represent the declared baseline for the mission period.
5. Enable baseline deviation detection ruleβ
Enabling too early guarantees noise - it will alert on ALL new inventory additions after enablement.
Detection rules can be managed in Kibana under Security β Rules
Rule: [262][Inventory] Inbound flow to new destination IP/port pair added to baselineβ
- Detection logic:
Alert when an inbound flow to a new destination IP/port pair within the DAL was added to the baseline inventory
- Only enable after:
- Baseline window is complete
- Hosts and sensors are stable
- Long-tail review is finished
- Ongoing alert tuning:
- Whitelist alerts with flows missed during baseline
- Suppress known admin or maintenance behavior
This rule is intended to catch:
- Inbound connections from unexpected sources